Fix OutputCache caching truncated responses for aborted requests - #66954

Fixes #66877

Problem

OutputCacheMiddleware can cache an empty or truncated response when the request that populates the cache is canceled. The broken entry is then served to all subsequent clients until it expires.

This happens because the existing cacheability checks have two blind spots:

The Content-Length check is bypassed when the header is absent (e.g. ResponseCompression removes it).

A decorator stream layered above OutputCacheStream (e.g. GZipStream) can throw OperationCanceledException before the write reaches OutputCacheStream, so BufferingEnabled stays true even though the body is incomplete.

The locking path (SetLocking(true)) has an additional issue: concurrent requests waiting on the in-flight response are served directly from the OutputCacheEntry returned by ExecuteResponseAsync, bypassing the normal cacheability checks entirely.

Fix

Two targeted changes to OutputCacheMiddleware.cs:

1. FinalizeCacheBodyAsync — skip storing if RequestAborted is canceled:

// Do not cache a response whose originating request was aborted.
if (context.HttpContext.RequestAborted.IsCancellationRequested)
{
    _logger.ResponseNotCached();
    return;
}

This is the right place because it is the single choke-point before every StoreAsync call. RequestAborted being canceled at this point is a strong, observable signal that the response body is incomplete — it is the token passed to WriteAsync in virtually every IActionResult implementation, and callers are expected to call httpContext.Abort() after catching OperationCanceledException mid-write.

2. ExecuteResponseAsync (locking path) — return null if the request was aborted after _next completes:

if (httpContext.RequestAborted.IsCancellationRequested)
{
    _logger.ResponseNotCached();
    return null;
}

Returning null here causes TryServeCachedResponseAsync to short-circuit, so no truncated entry is handed off to waiting concurrent requests.

Testing

The existing test FinalizeCacheBody_Cache_IfContentLengthAbsent and the locking tests continue to pass unchanged. The repro from the issue (OutputCache + ResponseCompression, client cancels after 1 s, subsequent request should get full payload) is the end-to-end verification scenario.